Web applications have been a prime target for application-level security attacks for several years. A number of attack techniques have emerged, including SQL injections, cross-site scripting, path traversal, cross-site request forgery, HTTP splitting, etc. Further, recent surveys have shown that the majority of Web sites in common use contain at least one Web application security vulnerability. In fact, in the last several years, Web application vulnerabilities have become significantly more common than vulnerabilities enabled by unsafe programming languages such as buffer overruns and format string violations.
While Web application vulnerabilities have been around for some time and some solutions have been developed, the recent popularity of interactive Web applications (e.g., “Asynchronous JavaScript and XML” (AJAX) based Web 2.0) has given rise to a new and potentially much more destructive breed of security threats typically called JavaScript worms. JavaScript worms and the like are enabled by cross-site scripting vulnerabilities in a widely used Web application. While cross-site scripting vulnerabilities have been a common problem in Web based-applications for some time, their threat is now significantly amplified with the advent of interactive Web technology, e.g., AJAX. AJAX allows HTTP requests to be issued by the browser on behalf of the user. It is no longer necessary to trick the user into clicking on a link, as the appropriate HTTP request to the server can just be manufactured by the worm at runtime. This functionality can and has been cleverly exploited by hackers to create self-propagating malicious JavaScript.
One of the first and infamous worms to date is the Samy worm that was released in a popular social networking site. By exploiting a cross-site scripting vulnerability in the site, the worm added close to a million users to the worm author's “friends” list. According to site maintainers, the worm caused an explosion in the number of entries in the friends list across the site, eventually leading to resource exhaustion. Two days after the attack the site was still struggling to serve requests at a normal pace.
The Samy worm gets its name from the login name of its creator. Initially, the malicious piece of JavaScript (referred to as the payload) was manually placed in Samy's own profile page, making it infected. Each round of subsequent worm propagation consists of the following two steps.
First Download: A visitor downloads an infected profile and automatically executes the JavaScript payload. This adds Samy as the viewer's “friend” and also adds the text “but most of all, samy is my hero” to the viewer's profile. Normally, this series of steps would be done through GET and POST HTTP requests manually performed by the user by clicking on various links and buttons embedded in the site pages. In this case, all of these steps are done in the background without the viewer's knowledge.
Second Propagation: The payload is extracted from the contents of the profile being viewed and then added to the viewer's profile. Note that one of the enabling characteristics of a worm is the interactive technique, e.g., AJAX propagation step. Unlike “oldstyle” Web applications, such techniques allow requests to the server to be done in the background without a user's knowledge. Without interactive programs such as AJAX, a worm such as Samy would be nearly impossible. Also observe that worm propagation happens among properly authenticated social networking site users because only authenticated users have the ability to save the payload in their profiles.
While Samy is a relatively benign proof-of-concept worm, the impact of similar type worms is likely to grow in the future. In fact, nowadays cross-site scripting vulnerabilities are routinely exploited to allow the attacker to steal the credentials of a small group of users for financial gain. Self-propagating code amplifies this problem far beyond its current scale. It is therefore important to develop a detection scheme for these types of worms before they become commonplace.
A comprehensive detection solution for such worms, however, presents a tough challenge. The server-side Web application has no way of distinguishing a benign HTTP request performed by a user from one that is performed by a worm using self-propagating code. An attractive alternative to server-side detection may be to have an entirely client-side solution. Similarly, however, the browser has no way of distinguishing the origin of a piece of code since benign code embedded in a page for reasons of functionality is treated the same way as the payload of a worm. In addition, filtering solutions proposed so far that rely on worm signatures to stop their propagation are ineffective when it comes to polymorphic or obfuscated payloads, which are easy to create. In fact many worms detected so far are in fact obfuscated. Moreover, overly strict filters may cause false positives, leading to user frustration if they are unable to access their own data on a popular Web site.